Per the comments, this is not uboot,env but the redundant forms.

Placed under fixed-partition nodes in order to add status = "disabled".
The roots are needed for u-boot envtools to use.

Signed-off-by: Rosen Penev <[email protected]>
Link: #16618
Signed-off-by: Robert Marko <[email protected]>

Needed to avoid probe errors.

There are two partitions from 0-20000 and 80000-100000.

This is redundant-count and not regular u-boot,env

Add status = "disabled" as the u-boot env driver can't handle redundant
environments properly. As a result, fw_printenv ends up not working
right.

Signed-off-by: Rosen Penev <[email protected]>
Link: #16618
Signed-off-by: Robert Marko <[email protected]>

The main point of it currently is to extract mac addresses. That is not
being done as MAC addresses are elsewhere.

Disable it until it becomes more feature packed and there's an actual
use for it.

All devices already have config definitions. NVMEM prevents redundant
support as well as write support.

Signed-off-by: Rosen Penev <[email protected]>
Link: #16618
Signed-off-by: Robert Marko <[email protected]>

meraki_loadaddr=1000000 may not enough to boot openwrt 25.12+ on mx60,
so directly sysupgrade without changing meraki_loadaddr would result
broken, but the u-boot-env partition used to be marked read-only, so
compat_version had better be incremented to show a notification to
direct users to the wiki to prepare the sysupgrade manually.

Signed-off-by: Edward Chow <[email protected]>
Link: #21912
Signed-off-by: Robert Marko <[email protected]>

Commit 01a87f4 changed the encryption
setting of the default SSID "OpenWrt" from "none" to "open". The correct
setting as per the documentation [1] is "none", though.
While this invalid setting won't cause a wrong hostapd setup, it will
at least cause malfunction in LuCI.

Change the default encryption setting back to "none".

[1] https://openwrt.org/docs/guide-user/network/wifi/basic#encryption_modes

Fixes: 01a87f4
Signed-off-by: Shine <[email protected]>
Link: #21925
Signed-off-by: Hauke Mehrtens <[email protected]>

The Sophos SG/XG-125 revision 3 like the already supported SG/XG-135
revision 3 has odd numbering of eth ports where the WAN port (as marked
on the case) is:  `eth6` and `eth0`, `eth1`, `eth2`, `eth3`, `eth5`, `eth7`,
`eth8` are LAN ports.

Port `eth4` confirmed to be the SFP port.

Signed-off-by: Raylynn Knight <[email protected]>
Link: #21914
Signed-off-by: Hauke Mehrtens <[email protected]>

When config_change is set during an active setup (e.g. by a concurrent
reconf call), wdev_mark_up() attempted to call setup() while still in
"setup" state. Since setup() requires state "up" or "down", it silently
returned, leaving the state as "setup". The subsequent wdev_setup_cb()
then treated this as a setup failure, triggering an unnecessary
teardown+restart cycle.

Fix this by removing the config_change handling from wdev_mark_up() and
moving it to wdev_setup_cb() instead. wdev_mark_up() now always
transitions to "up" state. When wdev_setup_cb() runs afterwards and
finds the device already "up" with config_change set, it initiates a
clean re-setup from the "up" state where setup() can run.

Signed-off-by: Felix Fietkau <[email protected]>

If nvmem is used for ethernet mac address, we need to defer loading to
get the proper mac.

Move to probe as ndo_init is the wrong place to handle EPROBE_DEFER.

Signed-off-by: Rosen Penev <[email protected]>
Link: #21920
Signed-off-by: Robert Marko <[email protected]>

Drop some lines that are not needed any longer.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #21929
Signed-off-by: Robert Marko <[email protected]>

The downstream Realtek phy module is currently known as rtl83xx-phy.c
and its kernel config REALTEK_SOC_PHY. It has been simplified, cleaned
and now aligns to Realtek main module (upstream Realtek phy). It is no
longer tied to the Realtek switch SoC but serves as generic module for
1Gbit multiport phys. Adapt it as follows:

- place it into the realtek folder aside its upstream sibling
- rename it to realtek_multiport.c
- remove SoC dependency in Kconfig and Makefile
- change kernel configs for the targets accordingly

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #21929
Signed-off-by: Robert Marko <[email protected]>

The bus reset functions currently configure a lot of things. Looking
closely they have a topology setup and a polling setup part. Split the
big chunk in smaller better readable functions.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #21906
Signed-off-by: Robert Marko <[email protected]>

Mikrotik RBM33G has got a USB-A port and mPCIe slots with USB 3.0 and USB
2.0 interfaces in use. The MediaTek MT7621 SoC has got an xHCI to provide
these interfaces. Therefore, enable kmod-usb3 to support them.

Fixes: 5684d08 ("ramips: Add support for Mikrotik RouterBOARD RBM33g")
Signed-off-by: Chester A. Unal <[email protected]>

Currently, for targets that use the CONFIG_TARGET_ROOTFS_TARGZ a single
rootfs tarball is generated for the subtarget based of $(TARGET_DIR).

However, this means that it does not respect DEVICE_PACKAGES like other
rootfs images.

So, lets augment CONFIG_TARGET_ROOTFS_TARGZ by adding a proper targz fstype
so that per device rootfs is generated under lock.

This is required so that devices that use custom sysupgrade archives like
Methode devices, can actually include a per device rootfs so when building
for multiple devices and with CONFIG_TARGET_PER_DEVICE_ROOTFS set the built
image actually includes the listed DEVICE_PACKAGES.

Signed-off-by: Robert Marko <[email protected]>

Use the added support for generating per device targz rootfs so that images
generated for Methode devices when CONFIG_TARGET_MULTI_PROFILE and
CONFIG_TARGET_PER_DEVICE_ROOTFS are set, we actually get the targz rootfs
that respects DEVICE_PACKAGES.

Currently, buildbot generated images have no networking, LM75 nor I2C
working, as the generated images do not include required kmods that are
listed in DEVICE_PACKAGES.

While at it, there is no need for tar to run in verbose mode.

Fixes: 7dff6a8 ("mvebu: uDPU: add sysupgrade support")
Signed-off-by: Robert Marko <[email protected]>

 7e5b324 instance: check length of names when creating cgroups
 014f94c procd: jail/cgroups: fix OOB write in cgroups_apply()
 e08cdc8 hotplug-dispatch: fix filter disallowing setting PATH
 afa4391 service instance: Improve handling of watchdog config changes
 52c64d2 service instance: Fix overwriting of watchdog linked list members
 96c827f coldplug: fix missing header include
 6b10c71 hotplug-dispatch: fix missing header include
 58d7aaa initd/coldplug: create /dev/null before running udevtrigger
 64f97ff hotplug-dispatch: redirect output to /dev/null
 c4e9859 hotplug-dispatch: use stat if d_type is DT_UNKNOWN
 bafdfff system: fix arguments validation in ubus handler

Signed-off-by: Daniel Golle <[email protected]>

Upstream solution came with 6.4. Seems quilt refreshed it to the extent
that it basically gets applied twice.

Signed-off-by: Rosen Penev <[email protected]>
Link: #21954
Signed-off-by: Hauke Mehrtens <[email protected]>

patch netlink headers for netifd PSE support
& fix PSE backports for PSE Prio

The 626-* patches are backporting net PSE-PD from
linux 6.18 to 6.12. The 627-02 is a nearly verbatim
copy of the upstream commit. The 6.12-01 patches the
auto generated ethtool_netlink_generated header.

The 6.12 build tools do not have the build system
feature for generating the correct netlink
headers related to the backports.

Signed-off-by: Carlo Szelinsky <[email protected]>
Link: #21926
Signed-off-by: Hauke Mehrtens <[email protected]>

There is a missing tab in one of the cases of MAC address configuration.

Signed-off-by: Jan Hoffmann <[email protected]>
Link: #21644
Signed-off-by: Hauke Mehrtens <[email protected]>

The MAC address assignment for XikeStor SKS8300-8T and SKS8300-12E2T2X
is semantically identical to the first case, so let's combine them.

Signed-off-by: Jan Hoffmann <[email protected]>
Link: #21644
Signed-off-by: Hauke Mehrtens <[email protected]>

Currently, the 02_network script always configures MAC addresses for
each individual LAN port unless "lan_mac_start" is set to "skip". This
behaviour can be unexpected, and is also somewhat broken, as it even
continues to do so when "lan_mac_start" is empty.

Change it to only do the configuration if "lan_mac_start" is non-empty,
and also remove the fallback to "lan_mac", making this more obvious and
less error-prone.

Signed-off-by: Jan Hoffmann <[email protected]>
Link: #21644
Signed-off-by: Hauke Mehrtens <[email protected]>

Explicitly specify all devices where the MAC address is configured based
on the U-Boot environment.

This change makes it clearer which devices use this method. Also makes
things simpler for any future devices which handle MAC address
configuration entirely via device tree.

Signed-off-by: Jan Hoffmann <[email protected]>
Link: #21644
Signed-off-by: Hauke Mehrtens <[email protected]>

Only configure the eth0 MAC address when it is not already done in the
device tree. To do this, create a new variable "eth0_mac".

Also avoid setting "label_mac" for devices already having it defined in
the device tree.

Signed-off-by: Jan Hoffmann <[email protected]>
Link: #21644
Signed-off-by: Hauke Mehrtens <[email protected]>

This reverts commit 66a7e04.

Doing so makes the u-boot unable to find the node for this pcie
controller and disable it on mx60, resulting boot failure, as reported
in #21649 .

If we keep on treating mx60 and mx60w the same target, we might have
to endure the warning which 66a7e04 wants to eliminate.

Signed-off-by: Edward Chow <[email protected]>
Link: #21941
Signed-off-by: Robert Marko <[email protected]>

On the kirkwood target, packages would frequently fail to install with
APKE_ADB_SCHEMA, APKE_ADB_BLOCK, and/or segfaults. The culprit was
unaligned access leading to bogus values being read out of memory on
these particular ARMv5 CPUs.

Pull in the relevant upstream fixes to address this.

Fixes: #21307
Link: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/391
Link: https://gitlab.alpinelinux.org/alpine/apk-tools/-/merge_requests/392
Signed-off-by: Matt Merhar <[email protected]>
Link: #21958
Signed-off-by: Robert Marko <[email protected]>

These devices share the same "compatible" in device tree causing some
incompatibilities (sysupgrades, ASU profile identification), assign a
unique "compatible" and "model" to each variant.

Context:
Commit [1] added each variant's dts compatible to the SUPPORTED_DEVICES
field of the other variant to make easy sysupgrades between these
physically indistinguishable devices variants possible.

But there were found three issues which does not allow this:
- the sysupgrade's stricter check still used in some sysupgrade
paths(this check is being replaced(and redundant) with the newer fwtool's
SUPPORTED_DEVICES check using the info in images METADATA), this check
will fail when sysupgrading from a different board_name(compatible dts)
that the image was created for (image profile name).[2]
- ASU needs unique "dts compatible" to identify the devices profile.
- and an ASU's profile identification limitation when several devices from
a common target share SUPPORTED_DEVICES entries.[3]

There is a proposal for these issues but not yet implemented [4][3].

Until these issues are fixed we won't allow "easy" sysupgrades between
these two device variants.

Commit [5] avoided the ASU profile identification limitation but
missed the required two unique dts compatibles in order to make the two
variants fully work, although not allowing easy sysupgrade between them.

[1]: 8d30e07
[2]: sysupgrade stricter check #20566 (comment)
[3]: ASU proposal openwrt/asu#1533
[4]: allow easy sysupgrade proposal #20947
[5]: b71f466
Fixes: b71f466 ("mediatek: filogic: fix supported_devices list for gl-mt2500")
Fixes: 8d30e07 ("mediatek: filogic: fix for new GL.iNet GL-MT2500/GL-MT2500A hardware revision")
Fixes: #20566
Fixes: openwrt/asu#1525

Signed-off-by: Mario Andrés Pérez <[email protected]>
Link: #21842
Signed-off-by: Hauke Mehrtens <[email protected]>

69a5afc9713a bridge: skip present toggle in bridge_free_member() when device is active

Signed-off-by: Felix Fietkau <[email protected]>

The configuration for the dlink,dir-1360-a1 also changed the settings
for the devices defined on top of it. "lan1 lan2 lan3 lan4" "wan" is
the default configuration, no need to add it here.

Fixes: 7a8e2ef ("ramips: add support for D-Link DIR-1360 A1")
Reported-by: schmars in IRC
Link: #22179
Signed-off-by: Hauke Mehrtens <[email protected]>

The key variable is not defined in the scope when setting wpa_psk. Use
config.key instead.
This fixes configuration the 64 characters wpa_psk directly.

Reported-by: donjoe in OpenWrt Forum
Link: #22182
Signed-off-by: Hauke Mehrtens <[email protected]>

Activate the option BRCMFMAC_SDIO by default on x86 too. x86 already
compiles MMC support into the kernel. This will just compile brcmfmac
with MMC support.

Fixes: #22155
Link: #22171
Signed-off-by: Hauke Mehrtens <[email protected]>

Bump optee-os-stm32 to upstream release 4.9.0.

Signed-off-by: Thomas Richard <[email protected]>
Link: #21965
Signed-off-by: Hauke Mehrtens <[email protected]>

Bump uboot-stm32 to upstream release 2026.01.

Two upstream patches were backported to resolve silent crash on
STM32MP135F-DK board.

Signed-off-by: Thomas Richard <[email protected]>
Link: #21965
Signed-off-by: Hauke Mehrtens <[email protected]>

Bump arm-trusted-firmware-stm32 to upstream release v2.14.

Signed-off-by: Thomas Richard <[email protected]>
Link: #21965
Signed-off-by: Hauke Mehrtens <[email protected]>

Enable and configure DMA contiguous memory allocator. Without this
CMA itself will be disabled.

Fixes: ae8bf1a ("imx: add imx8m support")
Signed-off-by: Tim Harvey <[email protected]>
Link: #21950
Signed-off-by: Robert Marko <[email protected]>

CONFIG_REGULATOR_QCOM_USB_VBUS showed up on Layerscape recently, and it
looks like multiple targets disable it manually, so simply disable it in
generic configuration instead.

Signed-off-by: Robert Marko <[email protected]>

Instead of disabling CONFIG_REGULATOR_QCOM_SPMI manually per target,
lets simply disable it in generic config.

Signed-off-by: Robert Marko <[email protected]>

CONFIG_REGULATOR_QCOM_LABIBB is being disabled by targets manually, so
instead lets disable it in generic config.

Signed-off-by: Robert Marko <[email protected]>

This reverts commit 9dbd45c.

Compared to ralink,mtd-eeprom , the nvmewm binding ends up byteswapping
the data on big endian hosts. Meaning on big endian, the nvmwem binding
is equivalent to:

ralink,mtd-eeprom +
ralink,eeprom-wrap

Revert as a result since there's no eeprom-swap here.

Signed-off-by: Rosen Penev <[email protected]>
Link: #22192
Signed-off-by: Robert Marko <[email protected]>

Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.12.72

All patches automatically rebased.

Build system: x86/64
Build-tested: flogic/glinet_gl-mt6000
Run-tested: flogic/glinet_gl-mt6000

Signed-off-by: John Audia <[email protected]>
Link: #22191
Signed-off-by: Robert Marko <[email protected]>

Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.12.73

No patches rebased/checksum update only.

Build system: x86/64
Build-tested: flogic/glinet_gl-mt6000
Run-tested: flogic/glinet_gl-mt6000

Signed-off-by: John Audia <[email protected]>
Link: #22191
Signed-off-by: Robert Marko <[email protected]>

Changelog: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.12.74

No patches touched with this release.

Signed-off-by: John Audia <[email protected]>
Link: #22191
Signed-off-by: Robert Marko <[email protected]>

Once again there is a family_id check. This time around the irq
reactivation in the receive path. For cleanup and better readability
add a helper directly besides its already existing counterpart
rteth_confirm_and_disable_irqs(). With that drop unneeded defines.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22156
Signed-off-by: Robert Marko <[email protected]>

With latest refactoring irq activation and deactivation is side-by-side
in the code. This makes it easier to align these functions. Current
assumption is, that the ethernet irq is only called on one cpu and
napi handling does not interfere. So it should be totally fine to
run irq disabling (called from interrupt handler) without locks.
Nevertheless be defensive and add a lock(). So in the case the ethernet
irq is fired twice on two cpus (e.g. RTL931x) the code is on the
safe side.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22156
Signed-off-by: Robert Marko <[email protected]>

rteth_hw_receive() already has a loop that checks how much work
may be done. No need to repeat that in the caller too. While we
are here adapt the function prefix.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22156
Signed-off-by: Robert Marko <[email protected]>

Remove defines and variables that are no longer used.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22156
Signed-off-by: Robert Marko <[email protected]>

This is a preparation for the dsa fast_age() logic refactoring.
Rename two functions that will get removed later.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22145
Signed-off-by: Robert Marko <[email protected]>

Fast ageing of L2 entries is supported by DSA with two callbacks.

- port_fast_age(): age out for one port
- port_vlan_fast_age(): age out for one vlan on one port

Independent from the SoC it always boils down to issue a command
to the L2_TBL_FLUSH_CTRL register. Nevertheless the current
implemententation is repeated multiple times and makes use of
the family_id.

As a first refactoring step provide generic fast_age() functions
for RTL930x and RTL931x by rearranging the existing definitions
of vlan_port_fast_age().

The logic is as follows:

- provide a SoC dependent function that works with or without VLAN.
  When VLAN/VID = -1 only flush the specific port otherwise only
  flush given VLAN on port.
- provide a port_fast_age() helper that calls the SoC specific
  functions with VLAN = -1.
- provide a port_vlan_fast_age() helper that calls the SOC specific
  functions and handing over the given VLAN.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22145
Signed-off-by: Robert Marko <[email protected]>

The driver has a generic fast_age() function. Use it in the
dsa specific callback port_fast_age() for RTL93xx.

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22145
Signed-off-by: Robert Marko <[email protected]>

Make use of the new fast_age() helpers for the RTL83xx targets.
For this:

- split the existing rtldsa_83xx_fast_age() into two device
  specific functions. This removes a family_id check.
- change the callbacks in the config structures

Signed-off-by: Markus Stockhausen <[email protected]>
Link: #22145
Signed-off-by: Robert Marko <[email protected]>

Fixes: #21187
Fixes: #21349
Fixes: 499a59c ("kernel: bump 6.12 to 6.12.30")
Signed-off-by: Rafał Miłecki <[email protected]>

Advertise the default 'not set' of this CONFIG higher in the tree since
it's already referenced by several other targets, with a few more targets
missing this reference (which fails build to prompt for N/y/m).

Signed-off-by: Bevan Weiss <[email protected]>

Prepare portmasks, vlan profiles and vlans for changes
in upcoming patches by exporting them to debugfs for easier
debugging and monitoring.

Signed-off-by: Linus Lüssing <[email protected]>
Link: #21872
Signed-off-by: Robert Marko <[email protected]>

The special all-ports multicast portmasks table entry would be written
twice, redundantly as vlan_profile_setup() is called twice. Which is
unnecessary. Writing this reserved multicast portmask entry is
independent of a VLAN profile, therefore let's move this to a more
suitable position.

Signed-off-by: Linus Lüssing <[email protected]>
Link: #21872
Signed-off-by: Robert Marko <[email protected]>

So far we are only associating and using a VLAN profile ID of 0 to any
VLAN ID, VLAN profile ID 1 is unused. Therefore we can safely remove its
initialization, just like we don't initialize any of VLAN profile IDs
2 to 7 on rtl83xx/rtl930x or 2 to 15 on rtl931x.

Signed-off-by: Linus Lüssing <[email protected]>
Link: #21872
Signed-off-by: Robert Marko <[email protected]>

The device has 1 100MBit/s port. By default the PHY firmware is running
in 1GBit/s mode. The driver will try to load the 1GBit/s firmware and
fail if it is not there. Set the GPHY0 also to 100MBit/s mode.

The driver uses all nodes independent of the status attribute.

Do the same fix for AVM FRITZ!Box 7412 too.

Reported-by: Achelon in OpenWrt forum
Fixes: #21836
Link: #22188
Signed-off-by: Hauke Mehrtens <[email protected]>